feat: Support Argo CD Agent's Agent Component in operator #1913
Conversation
mikeshng
force-pushed
the
add-agent-agent-components
branch
5 times, most recently
from
7fed99e to
8459234
Compare
| SecretKeyRef: &corev1.SecretKeySelector{ | ||
| Key: AgentRedisPasswordKey, | ||
| LocalObjectReference: corev1.LocalObjectReference{ | ||
| Name: AgentRedisSecretname, |
There was a problem hiding this comment.
I think this should be <argocd name>-redis-initial-password otherwise it will not work if instance name in not "argocd", it seems I missed it in principal as well https://github.com/argoproj-labs/argocd-operator/blob/master/controllers/argocdagent/deployment.go#L379
There was a problem hiding this comment.
I fixed principal deployment #1926
|
I tried it locally and connected it with principal, it worked for me. |
mikeshng
force-pushed
the
add-agent-agent-components
branch
from
8459234 to
d1170cc
Compare
|
Thanks Mike, both of my PRs are now merged. |
Thank you. My PR has been updated as well. |
|
Thanks @mikeshng LGTM |
mikeshng
force-pushed
the
add-agent-agent-components
branch
from
d1170cc to
8112fb4
Compare
|
@jparsai I've rebased and ran |
|
@jparsai sorry i think I messed up my rebase! |
mikeshng
force-pushed
the
add-agent-agent-components
branch
from
8112fb4 to
d1170cc
Compare
Signed-off-by: Mike Ng <[email protected]>
mikeshng
force-pushed
the
add-agent-agent-components
branch
from
d1170cc to
81fcc4d
Compare
|
@jparsai OK much better now. My bad! |
|
LGTM |
|
Follow up PR: #1930 |
3 participants
What type of PR is this?
/kind enhancement
What does this PR do / why we need it:
The ArgoCD operator is already capable of deploying the argocd-agent's principal components. This PR adds support for deploying the argocd-agent's agent components as well, allowing users to use the ArgoCD operator to deploy both the principal and agent components.
Have you updated the necessary documentation?
Which issue(s) this PR fixes:
Fixes #NA
How to test changes / Special notes to the reviewer:
I've intentionally avoided disrupting the existing Principal path to minimize regression risk. To keep concerns separated, this PR introduces an agent/ folder that mirrors the structure of the current Principal code. This separation is both safer (fewer unintended cross effects) and more future proof, since the Principal (server) and Agent (client) are likely to diverge further over time. While this does introduce some code duplication, sharing helpers between two components with distinct roles (server vs client) increases the chance that a change for one will accidentally impact the other. That's why I feel like clear boundaries are preferable here.
I also considered creating a principal folder and moving existing files, but that would add a lot inflate this PR. For now, the top level continues to represent the server (Principal), and the new agent folder represents the client, which still reflects a clean server–client structure without unnecessary file moves.